Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] 3D viewers integration #1259

Merged
merged 31 commits into from
Jul 17, 2024

Conversation

markusweigelt
Copy link
Contributor

  • Add middleware for embedding installed 3D viewers via iframe
  • Adjust current implementation and remove unnecessary files
  • Implement error handling to account for multiple scenarios
  • Documentation (Setup, configuration and creating custom viewers)
  • Bugfixes of NPE and loading METS/MODS documents

@markusweigelt markusweigelt changed the title 3D viewers integration [FEATURE] 3D viewers integration Jun 12, 2024
@sebastian-meyer sebastian-meyer self-requested a review July 11, 2024 06:36
@sebastian-meyer sebastian-meyer added the ⚙ feature A new feature or enhancement. label Jul 11, 2024
@sebastian-meyer
Copy link
Member

I like the improved documentation and more robust integration via middleware, but I think we should provide a default configuration which works out-of-the-box. So, there should be at least one default viewer pre-configured and all necessary files bundled with Kitodo.Presentation. I'd prefer three.js as default, but that's up to you!

Also, the default in documentation and configuration should be for all viewers to host their components (third-party libraries, configs, styles, etc.) locally with Kitodo.Presentation, because there are multiple users which run Kitodo in a controlled environment without access to the internet.

@markusweigelt
Copy link
Contributor Author

markusweigelt commented Jul 15, 2024

I like the improved documentation and more robust integration via middleware, but I think we should provide a default configuration which works out-of-the-box. So, there should be at least one default viewer pre-configured and all necessary files bundled with Kitodo.Presentation. I'd prefer three.js as default, but that's up to you!

No problem, we can provide a default implementation, but we should discuss the default viewer. Three.js is a framework (sometimes described as a full game engine) with multiple options, such as lights, texture rendering, and loaders for different model types. However, it is not a fixed viewer. With Three.js, you can implement a viewer for specific cases, but this could lead to a maintenance burden that could hinder further development of the DFG-viewer. (In general, I think we should move such complexities to separately versionable components.)

That's why I think the model-viewer (based on Three.js) is more suitable because the maintenance effort is very low. In the best case, only the version number needs to be adjusted, and in the worst case, some attributes of the HTML tag might need updating. The disadvantage is that only glTF/GLB 3D models are supported.

Also, the default in documentation and configuration should be for all viewers to host their components (third-party libraries, configs, styles, etc.) locally with Kitodo.Presentation, because there are multiple users which run Kitodo in a controlled environment without access to the internet.

All our current viewer implementations at https://github.com/slub/dlf-3d-viewers can run locally. Otherwise, I believe it is the responsibility of our implementation repository and not part of this PR.

Only the Kompakkt Viewer itself can be explicitly installed on a local system. I will add an option to set your own instance there. By default, it uses the University of Cologne's Kompakkt instance.

If I misunderstood anything, we can certainly discuss it further to clarify. :)

@sebastian-meyer
Copy link
Member

That's why I think the model-viewer (based on Three.js) is more suitable because the maintenance effort is very low. In the best case, only the version number needs to be adjusted, and in the worst case, some attributes of the HTML tag might need updating. The disadvantage is that only glTF/GLB 3D models are supported.

Perfect! Then let's use the model-viewer as a default. Since glTF/GLB is the most common 3D format, I think it's reasonable to only support those with our default configuration.

If I misunderstood anything, we can certainly discuss it further to clarify. :)

What I meant is, that all files should be hosted on the Kitodo server and not loaded from their original source or some kind of CDN. The Kompakkt viewer is special, because AFAIK it's the only viewer which needs its own server-side backend.

@markusweigelt
Copy link
Contributor Author

What I meant is, that all files should be hosted on the Kitodo server and not loaded from their original source or some kind of CDN.

This is taken into account with the implementation repository. There is an installation script that downloads the respective resources and adds them to the viewer as a module folder.
For the default viewer, I will include it in the Kitodo.Presentation installation instructions or should the library be added to the source code?

@sebastian-meyer
Copy link
Member

Please add the default viewer to the source code (in its own sub-directory of Resource/Public/JavaScript/) so we can exclude it from automatic static code analyzing. Installing Kitodo.Presentation should be as easy as possible. Thank you!

ext_conf_template.txt Show resolved Hide resolved
Resources/Private/Templates/View3D/Standalone.html Outdated Show resolved Hide resolved
Copy link
Member

@sebastian-meyer sebastian-meyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much!

@sebastian-meyer sebastian-meyer merged commit 729110e into kitodo:master Jul 17, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⚙ feature A new feature or enhancement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants